<h1>Timelines and workfow</h1>
<h2>
	<br /> The Timeline
</h2>
<p>You may have noticed the the image shown at the bottom right of
	the front page of the site. In fact it is almost identical to how the
	Google Summer of code works, if you are familiar with it.</p>
<p>
	<img src="images/timeline.jpg" alt="timeline" width="180" height="298"
		class="img-left-align" /> This image shows the current period of the
	Semester of code. There are 3 distinct periods during the Semester of
	code. <em>(There are some smaller periods interspersed also.)</em>
</p>
<ol>
	<li>Organisation/Institution application period (or organisation
		signup period)<br />
	</li>
	<li>Student applications period (or student signup period)<br />
	</li>
	<li>Coding period</li>
</ol>
<p>
	Most of the activity in the system takes place during these 3 periods.<br />
	<br />
</p>
<h3>Organisation/Institution application period</h3>
<p>During this period we initially invite organisations and
	institutions to register into the system.</p>
<p>For organisations we initially make contact with someone from a
	particular organisation who wants to be involved, be a mentor for and submit
	possible project ideas for students. Once the contact is established a
	generic 'organisations' code is privately sent to that individual by
	email. That person will use the code to register into the system as the
	lead organisation administrator for that particular organisation. Once
	this is setup, the newly created organisation profile will have its own codes
	for inviting other users. They are then encouraged from that point on
	to invite other members of their organisation to signup using the code
	key which relates to their organisation. As more mentors are added to
	an organisation, the hope is that more project ideas are added for
	prospective students.</p>
<p>The process is almost identical for institutions. Partner
	universities and institutions are encouraged to nominate someone to act
	as the initial lead institute administrator for that particular
	university. That person uses a generic 'institution' code to setup
	their institutions profile into the system. Again, that person can invite other
	members of staff from their institution using a institution specific
	generated code for colleague admins or student supervisors.
	Supervisors are encouraged to browse the list of project ideas
	submitted by organisations and mark out any that they feel comfortable
	they could supervise students with. Later on, students will choose a supervisor they like to work 
	with seeing the list of supervisors liking this project. Furthermore, supervisors can give comments on 
	projects as suggestions to the mentors to shift the focus or comment on how they see this project
	fit into the curriculum of the students. People can give comments on eachothers comments perhaps to ask questions,
	clarify things and so on. Students generally do not enter the
	system yet, but if added during this period, their options are very
	limited until the next period opens.</p>
<h3>Student applications period</h3>
<p>During this period students become active in the system,
	essentially meaning that they can browse the project ideas, mark their favourites 
	and start to write proposals for 
	one or more of the project ideas. Normally they would
	first create a project proposal and save it in draft mode. Together
	with their supervisor they can refine it and when ready, also choose to
	make it accessible to the project mentor by saving it as 'open draft'
	or as 'final'.</p>
<p>The mentor can now provide feedback on the proposal. He/she can
	decide to mark a particular proposal as their 'interim' choice, meaning
	they can change their mind if they receive a superior proposal for that
	project idea. Alternatively they can decide to choose this particular
	proposal and set it as their final choice. This means that the project
	is now being 'offered' to that student.</p>
<p>The student now has to login to the system and choose whether to
	accept this project offer. If they decide to accept it, that project is
	set as their final project for the Semester of Code and it is the one they
	will start to work on.</p>
<p>Projects for which the offers is rejected by the student (he/she had more
	than one offer and chose another for example) are made available again in the
	system. This means that the mentor can now offer the project to another
	student instead.</p>
<p>For all of these state changes in projects, the involved persons are acknowledged by email.</p>

<h3>Coding period</h3>
<p>The student works on the project.</p>
<h2>&nbsp;</h2>
<h2 id="workflow">
	Workflow
</h2>
<p>In essence the workflow can be boiled down to the following
	sequence</p>
<ol>
	<li>Organisation and institution admins register in the system and
		optionally invite others to participate</li>
	<li>Mentors and supervisors register in the system<br />
	</li>
	<li>Mentors create and add projects to the system<br />
	</li>
	<li>Supervisors mark which project ideas they would ideally like
		to supervise students with (optional)<br />
	</li>
	<li>Supervisors create 'groups' in which to add students to
		(optionally there is just one group for everyone)<br />
	</li>
	<li>Students register into the system</li>
	<li>Students browse the list of projects and decide which one/s
		they would like to tackle as their project and marks them as favourite.</li>
	<li>Students start to write proposals and save them in 'draft'
		mode. This means only the student and his/her supervisor can see it.</li>
	<li>When the student &amp; supervisor are happy with the proposal
		they can either choose step 10 or 11 (or a series of both).</li>
	<li>Student saves the proposal as 'open draft', which means that
		now the project mentor can also see it, while still allowing the
		student to make changes to it.</li>
	<li>Student saves the proposal as 'final' which means it can no
		longer be edited and is set to the final version. <em><strong>Note:</strong>
			some mentors may ask that the proposal is set to 'final' before
			making a project offer to a student.</em>
	</li>
	<li>The mentor reviews the list of proposals for a particular
		project idea. Optionally they can either...<br /> <br />
		<ul>
			<li><em> accept one proposal as their interim choice. This
					means that although it is their current preferred proposal for this
					project idea, they may still change their mind later.<br />
			</em></li>
			<li><em> accept one proposal as their final choice. This
					means that the mentor has decided to offer the project to the
					student who created this particular proposal. </em></li>
			<li><em> reject a particular proposal, but also giving some
					sort of feedback on why. </em></li>
		</ul>
	</li>

	<li>The student now has to decide whether to accept the offer. If
		the student just has one offer, then he/she would accept that offer,
		meaning that this project idea is now taken and is being completed by
		him/her. Any other proposals for this particular project idea made by
		other students have been unsuccessful and so are now marked as
		'archived' in the system.</li>
	<li>If the student has multiple project offers, the situation is a
		little more complex. When the student chooses between more than one
		offer, any other offer he/she had from another mentor becomes void,
		meaning that its 'final' state is reset, allowing the mentor to offer
		the project to another student.<br />
	</li>
	<li>The student, mentor and the students supervisor can all now
		optionally work on agreeing what work will take place, milestones etc,
		using an agreement form. This is optional, as this may have been done
		already in the proposal, or is not required by the parties involved. Signing an 
		agreement form makes (additional) expectations from both sides clear and also clearly
		marks the beginning of the work.</li>
	<li>The student now enters the coding phase and starts the project
		work</li>
	<li>Towards the end of the coding period the student ensures that
		the work done is availbale to the supervisor and mentor for review.</li>
	<li>After the coding period, the supervisor and mentor discuss the
		work done by the student.</li>
	<li>There is an informal review with student, mentor and
		supervisor (optional).</li>
	<li>The student, supervisor and mentor sign off the students work
		by confirming that they are satisfied.</li>
	<li>The student now gains merit or credits, on whatever part of
		their studies was agreed to with their supervisor.</li>
</ol>

<h2>Timekeeping</h2>
<p>All dates and times on the website are expressed in Coordinated
	Universal Time (UTC).</p>